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(54) Secure computing device 

(57) A secure computing system (1 00) stores a pro- 
gram, preferably the real time operating system (210), 
that is encrypted with a private key. A boot ROM (135) 
on the same integrated circuit as the data processor 
and inaccessble from outside includes an initialization 
program and a public key corresponding to the private 
key. On initialization the boot ROM decrypts at least a 
verification portion of the program. On verffication nor- 
mal operation is enabled. On non-verification, the sys- 
tem could be disabled, or that application program could 
be disabled. A diagnostic program is stored at predeter- 
mined non-relocatai3le physical address in memory. The 
program Is made non-relocatat^le using a special table 
look-askJe buffer (137) having a fixed virtual address 
re^ster (611) and a corresponding fixed physical 
address register (641). The secure computing system 



prevents unauthorized use of compressed video data 
stored in a f irst-ln-f irst-out memory buffer tsy encrypting 
the compressed vUeo data stream using at least a part 
of the chip dentHy number as an encryption key (703). 
The data is recalled from memory (705) and decrypted 
(706) as needed for video decompression. The debug- 
ger/enuilator tool comnnonly employed in program 
development is protected by a private encryption key 
used to encrypt at least verif icatton token ftor the pro- 
gram. Upon each initialization of the detxjgger/ emula- 
tor, the secure computer system deaypts the 
verification token employing public decryption key (805) 
to indicate whether the program is secure or non- 
secure. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001] The technical field of this invention is secure 
computing systems, especially computer systems that 
may execute after manufacture field provided programs 
secured to prevent the user from unauthorized use of 
selected computer services. The computer system may 
also be functionally reprogrammable in a secure man- 
ner. 

BACKGROUND OF THE INVENTION 

[0002] There are currently many methods to deliver 
video programming to users of television besides ever 
the air broadcast Numerous service providers are 
available to supply this progranvning to television viewf- 
ers. Most of these service providers vend a hierarchy of 
services. Typically there is a basic sen^lce for a basic 
fee and additional services available for an additional 
fee. The basic services typically include the broadcast 
network programming, cable superstations. music and 
sports programming. These basic services are typically 
supported by advertizing. These basic programming 
services thus operate on the same economics as over 
the air broadcast television. The additional services typ- 
ically include the so called "premium" programming 
such as sports and nxTvies. These prenuum program- 
ming services are typically not advertizer sipported. 
These are perceived k}y the television user as higher 
value services and television users are willing to pay 
their service providers additional fees for these serv* 
ices. The service provider passes much of this addi- 
tional fee to the content providers as their compensation 
for supplying the programming. There may be one or 
several tiers of these premium services made availak)le 
by the service providers. At the top of this programming 
hierarchy is pay per view programming. Pay per view 
programming typically includes music concerts and 
sportng events perceived as time sensitive and highly 
valuable by the television users. P&y per view may also 
include video on demand, where the television user 
requests a particular movie be supplied. This hierarchy 
of service exists for all cun^ent alternative methods of 
program delivery including television cable, over the air 
microwave broadcast and direct satellite television. . 
[0003] Reception of such alternative programming 
services has required an additional hardware appliance 
beyond the user provided television receiver since the 
beginning of cable television. Initially this additional 
hardware appliance merely translated the frequency of 
the signal from the transmission frequency to a stand- 
ard frequency used in broadcast television. Such a 
standard frequency is receivable by the user provided 
television receiver. This additional hardware appiiarKe 
is commonly know as a "set top box" in reference to its 
typical deployment on top of the television receiver. Cur- 



rent set top boxes handle the hierarchy of security pre- 
viously described. 

[0004] tn the past these set top boxes have been fixed 
function machines. This means ttiat tiie operattonal 

5 capabilities of the set top boxes were fixed upon manu- 
facture and not sutiject to change once installed. A per- 
son intending to compromise the security of such a set 
top box would need substantiid resources to reverse 
engineer the security protocol. Accordingly, such fixed 

10 function set top boxes are considered secure. The 
future proposals for set top boxes places the security 
assumption in jeopardy. The set top box currently envi- 
sioned fdr tiie future would be a more capable machine. 
These set top boxes are expected to enatde plural home 

15 entertainment opttons such as the prior known video 
programming options, viewing video programming 
stored on fixed media such as DVD disks. Internet 
browsing via a telef^ne or cable nxxJem and playing 
video games downloaded via the modem or via a vMeo 

20 data stream. Enabling ttie set top box to be pro- 
grammed after installation greatiy compficates security. 
It woukJ be useful in the art to have a secure way to ena- 
ble f iekJ reprogramming of set top boxes without com- 
promising the hierarchy of video programming security. 

SUMMARY OF THE INVENTION 

[0005] The present application disctoses a secure 
computing system. A program, preferably the secure 

$0 computing system real time operating system, is 
encrypted with a private key The data processor 
Includes a boot ROM on the same Integrated circuit that 
is inaccessible from outside the integrated circuit The 
boot ROM includes the pxAAtc key corresponding to the 

35 private key used to encrypt the program. On Initializa- 
tion ttie boot ROM deaypts at least a verificatk)n por- 
tion of the program. TTus enables verification or rx>n- 
verificafion of the security of the program. The boot 
ROM may store additional public keys for verification of 

40 application programs foltowing verification of the real 
time operating system. Alternatively, these additional 
public keys may be stored in tiie non-volatile memory. 
[0006] On verification of the security of the program, 
normal operation is enabled. There are several remedial 

45 actions ttiat can take place on non-verif ication, The sys- 
tem could be disabled, or in the case of non-verification 
of an application following verification of the real time 
operating system only that application program could be 
disabled. The system could notify the system vendor of 

50 ttie security violation using the modem of the secure 
computing system. 

[0007] A diagnostic program can check the security of 
a program. The program is stored at predetermined 
physical address in memory Relocation of these physi- 
55 cal addresses where the program is stored is prevented. 
The diagnostic program is loaded and checks ttie pro- 
gram at tfie predetermined physical address against a 
standard. The diagnostic program then indicates that 
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the program is verified as secure if it meets the standard 
or non-verified as secure if it does not meet the stand- 
ard. 

[0008] The program is made non-relocatable using a 
special table look-aside buffer. The table look-aside s 
buffer has a f ixed virtual address register and a plurality 
of writable virtual address registers. Each of these vir- 
tual address registers has a comparator and a oonre- 
sponding physical address register. The physical 
address register corresponding to the fixed virtual 10 
address register Is also fixed. The fixed virtual address 
register and the f ixed physical address register encom- 
pass the range of addresses where the program is 
stored. The fixed virtual address register and the fixed 
physical address register are preferably mask program- is 
mable in manufacture via a metal layer 
[0009] The fixed virtual address register and the fixed 
physical address register may be registers ostensibly 
writable via the instruction set architecture. In this case, 
attempts to write to these registers do not change their 20 
contents. In additbn, it is preferable that attempts to 
write to these registers produce no faults or exceptions. 
Alternatively, the fixed vblual address register and the 
fixed physical address register may not be accesstole 
via the instruction set architecture. 
[001 0] The disclosed embodiment of the secure com- 
puting system prevents unauthorized use of com- 
pressed video data stored in a first-in-first-out memory 
buffer in a set top box. Current video compression tech- 
niques do not compress data uniformly. For this reason 30 
a uniform compressed video data rate does not trans- 
late into a uniform decompressed video data rate. Typi- 
cal set top boxes empkiy off chip DRAM as a first-in- 
first-out (FIFO) buffer to prevent the decompression 
process from overflowing or underf towing. The memory 35 
bus traffic between the data processor and the portion 
of memory used as the FIFO buffer Is subject to inter- 
ception and unauthorized use. 
[0011] The data processor is disposed on a single 
integrated circuit This data processor includes a chip 4o 
identity read only register storing a unique chip k:lentity 
number. TN's unk^e chip identity number is fixed during 
manufacture by, lor example, laser probing or selective 
activatton of fuse or antifuse links in the chip Klentity 
register. The data processor encrypts the compressed 4S 
vkJeo data stream using at least a part of the chqp klen- 
tity number as an encryption key. This encrypted data is 
stored in the memory area sennng as the FIFO buffer. 
The data is recalled from memory as needed for vUeo 
decompression. The date processor then decrypts the so 
recalled data employing at least a part of the chip iden- 
tity nunrrber as the decryption key. 
[0012] Using this technque the compressed vkJeo 
data stream temporarily stored in compressed form in 
the FIFO buffer can only be read by the particular data ss 
processor having the unk^ue chip identity nunU^er. Since 
the chip identity number is unique to that particular data 
processor the vkleo data cannot be processed by 
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another data processor, even another kJentical set top 
box system without breaking the code. The encryption 
and decryption is transparent to the user requiring only 
a small additional processing capacity within the data 
processor. 

[001 3] Another aspect of this invention concerns the 
security of a computer system when used with a det^ug- 
ger/emulator tool commonly employed in program 
development Without special procedures to limit the 
operation of the debugger/emulator tool, the security of 
the computer system wouU be subject to compromise. 
[0014] The disctosed embodiment of the secure com- 
puting system uses an encryptk)n system emptoying a 
private encryption key and a public decryption key. The 
private encryption key is used to encrypt at least a veri- 
fication token for the program. The pubFic decryption key 
corresponding to the private encryption key is stored at 
the secure computing system. Upon each initializatton 
of the debugger/emulator for the secure computing sys- 
tem a security screen is performed. This involved deter- 
mining if the program is secure program or a non- 
secure progrant The secure oomputer system decrypts 
the veriftoation token emptoying public deayption key. 
This decrypted verif cation token indrcates the program 
as a secure program or a non-secure program. If the 
program is a secure program, then the debugger/ emu- 
lator is operated in a process mode. The process mode 
permits the debugger/emulator access to the program 
while prohbiting access to at least one security feature 
of the secure computing system. If the program is a 
non-secure program, then the debugger/emulator is 
operated in a raw mode The raw nKXie permits ttie 
debugger/emulator to access an features of the secure 
computing systen^ 

[0015] A further security layer is used fa operating 
system devetopment intended for the secure computing 
system. Each data processor includes a unique chip 
kJentity number stored in a read only chip kientity regis- 
ter. If the program is a secure program, then the debug- 
ger/emulata reads the chip identity number. A certain 
subset of the chip identity numbers and only this sut}set 
will permit the debugger/emulator to operate in the raw 
for a secure program. If the dtap identity number does 
not fan within this sut>set then the debugger/emulator 
can only operate in the process mode. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] The present invention will now be further 
described by way of example, with reference to the 
accompanying drawings in which: 

Rgure 1 is a block diagram of one embodiment of 
the disclosed secure computing system; 
Rgure 2 is an exanple memory map of the boot 
read only memory of the digital media processor 
illustrated in Figure 1; 

Rgure 3 is an example memory map of the non-vol- 
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atile memory of the set top box illustrated In Figure 
1: 

Rgure 4 is an example memory map of the read 
write memory illustrated in Figure 1 ; 
Rgure 5 is a flow chart of the initial operation 
including the operating system verification of the 
digital media processor illustrated In Figure 1 ; 
Rgure 6 is a flow chart of the process for verifica- 
tion of an application to the set top box illustrated in 
Figure 1; 

Rgure 7 is a flow chart of the process of verification 

of a downloaded application program; 

Rgure 8 is a schematic diagram of a translation 

look aside buffer preventing virtual memory reloca* 

tion of a certain page of memory of the digital 

media processor of Rgure 1 ; 

Rgure 9 is a flow chart of the process of encrypting 

and decrypting compressed video data temporarily 

stored in random access memory; and 

Rgure 10 is a flow chart of the process of mode 

selection in a hardware debugger/emulator. 

DETAILED DESCRIPTION OF PREFERRED EMBOD- 
IMENTS 

[0017] The set top box of the futu'e will enable home 
entertainment options such as the known video pro- 
gramming options, viewing video progranvrung stored 
on fixed media such as digital video disks (DVD), Inter- 
net browsing via a telephone or cable modem arxJ play- 
ing video games downloaded via the modem or via a 
video data stream. Such a variety of capabiFity can only 
be provided by a fully programmable data processor 
which can receive and run downloaded programs. This 
opens up a host of security issues. Since much of the 
utility of the system depends on being able to downk)ad 
various applications, the possibility also exists for an 
unauthorized application being downtoaded. Such an 
unauthorized application may be deliberately written to 
compromise the hierarchy of security 
[001 8] Fully programmable set top boxes are vulnera- 
t>le to three main types of attacks. An unauthorized 
application may interact with the operating system, pos- 
sbly bypassing security. The set top box non-volatile 
memory may be replaced with wodftled resident appli- 
cations, but with the original operating system. The non- 
volatile memory may be replaced with a new operating 
system. The most important item to protect is the oper- 
ating system. If the operating system is compromised, 
an unauthorized person can do almost anyttiing, includ- 
ing disguising the fact that ttie operating system is com- 
promised. 

[001 9] Figure 1 illustrates in schematic form the parts 
of a versatile, programmable set top box system 100. 
Set top box system 1 00 is responsive to inputs from: tel- 
evision cable 101; direct satellite receiver front end 103, 
digital vkjeo disk (DVD) 105; an ordinary telephone line 
107; and infrared remote control 109. These inputs are 



conventional and need not be more fully described 
here. Any interaction of these conventional inputs witii 
the parts of the disctosed embodiment of the secure 
computing system will be more fully described below. 

5 [0020] The central part of set top box system 100 is 
the set top box 1 10. Set top box 1 10 incliKles various 
interfaces for the inputs including: vkfeo analog-to-dig- 
ital converter 111 connected to the television cable 101, 
which may optionally include a cable modem; vkieo 

10 analog-to-digital converter 1 13 connected to direct sat- 
ellite receiver front end 103: a DVD driver 115 capable 
of receiving and reading DVD 105; vok:e band modem 
117 connected to tel^hone line 107; and infrared 
receiver 119 capal^le of receiving the infrared signals 

IS from infrared remote control 109. 

[0021] Set top box 110 includes several output 
devices coupled to digital media processor 130. Video 
dig'ital-to-analog converter 121 receives a vkieo data 
stream from digital media processor 130 and supplies 

20 an conresponding video signal to television receiver 
151. Typically tiie desired vkleo data stream is modu- 
lated upon a earner having a frequency which the televi- 
sion receiver 151 can normally receive. It is 
contemplated tiiat vkieo media processor 130 in coop- 

25 eration with video digital-to-analog converter 121 will be 
capable of producing a vkieo signal In a plurality of for- 
mats. Upon set up of set top box system 100 the partic- 
ular format will be selected to correspond to the 
capability of the particular television receiver 151 

90 employed. Aucfio cfigital-to-analog converter 123 
receives an aucfio data stream from digital media proc- 
essor 130 and supplies a base band audio signal to 
audio system 153. It is contemplated that this audio sig- 
nal may encompass plural audio channels (i.e. left and 

35 right channels for stereo). It is also contemplated tiiat 
any particular vUeo source may include plural encoded 
audio data streams such as alternative languages, 
descriptive video or other separate audk> prograns 
(SAP). Note also that the audio data stream will typk:ally 

40 also be nrKxiulated on the same carrier as the video sig- 
nal for receptksn and demodulatton by televiskm 
receiver 151. 

[0022] The intelligent part of set top box 1 10 is digital 
media processor 130. Digital media processor 130 is 

45 preferably embodied in a single integrated circuit. Note 
tiiat in order for set top box 1 10 to be fully secure as 
intended, central processing unit 131 and boot ROM 
1 35 must be located on tiie same integrated circuit. [)ig- 
ital media processor 130 includes central processing 

so unit 131. Central processing unit 131 is illustrated 
generk:aily and is not intended to limit the structure 
emptoyed. Central processing unit preferably includes 
data processing capability for control functions required 
for selection of operating mode, channel tuning, security 

55 functions and the like. Central processing unit preferably 
also includes digital signal processing capability for 
decompressing compressed video and audk) signals, 
decrypting encrypted vkieo signals, converting the 
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received video to the format of the user's television 
receiver, operating as a ''software" calsle modem and 
voice band modem and demodulating the signal from 
infrared remote control 109. Central processing unit 131 
may Include a microprocessor and a digital signal proc- s 
essor, a single data processor capable of all the neces- 
sary functions or a multiprocessor. The exact nature of 
central processing unit, except for details noted below, 
is not relevant to disclosure of the present application. 
[0023] Digital media processor 130 further Includes io 
chip identity register 133. Chip identity register 133 is a 
programmable readable register holding an identity 
number unique to the Integrated circuit embodying dig- 
ital media processor 130. This identity number is prefer- 
ably implemented as taught in U.S. Patent Application is 
No. 087813,887 entitled Circuits, Systems, aiHi Methods 
for Uniquely Identifying a Micropnxessor at tfie fnstruc- 
tton Set Level and filed March 7, 1997. As desaibed in 
this patent applicatioa the unique identification code Is 
formed in a read-only data register by laser probing fol- 20 
lowing integrated circuit test The unique chip identity 
number may be spedfM via selective blowing off fuse 
or antrfuse links or other techniques. This Identity 
number permits a program to verify the exact identity of 
the particular digital media processor 130 used in the 2s 
set top box 110. 

[0024] Digital media processor 1 30 includes boot read 
only memory (ROM) 135. Digital media processor 130 
is constructed so that central processing unit 131 
begins executing program Instructions stored witNn 30 
boot ROM upon each initial application of electric 
power. An exemplary memory map of boot ROM 135 is 
illustrated in Figure 2. Those skilled in the art will reaHze 
that the exact order of storage of the various parts Is not 
as important as the existence of the detailed data types, ss 
Boot ROM 135 Includes seH boot code 201. Self boot 
code 201 is the program instructions initially executed 
by central processing unit 131 upon each initial applica- 
tion of electric power to digital media processor 130. In 
addition the known processes for initializing computer 40 
systems, self boot code 201 also includes verification 
program code 202. Verification program code 202 will 
be further described befow in conjunction with Rgure 5. 
Boot ROM 135 also Includes a public signature keys. 
These public signature keys Include real time operating 4S 
system (RTOS) public signature key 203. first applica- 
tion public signature key 205. second applk^tion publk; 
signature key. to the Nth applicatfon pubilic signature key 
207. These public signature keys are employed In verifi- 
cation of the authorization of programs in a manner that so 
will be further desaibed below. 
[0025] Digital media processor 1 30 also includes table 
look-aside buffer (TLB) 137. Table look-askie buffer 137 
Is employed to enhance security during virtual memory 
operation In a manner further described below. 55 
[0026] Set top box 1 1 0 includes flash (electrically pro- 
grammable read only memory) EPROM 141 bi-direc- 
tionally coupled to digital media processor 130. Flash 



EPROM 141 serves as the non-volatile memory for set 
top box system 100. This is known as a non-volatile 
memory because it retains its corttents when electric 
power is turned "OFF". Non-volatile memory is needed 
for the real time operating system (RTOS) and for resi- 
dent applications. Rgure 3 Illustrates an exemplary 
memory map of flash EPROM 141. Flash EPROM 141 
includes the real time operating system (RTOS) 210. 
RTOS 210 includes program code enabling digital 
media processor 130 to receive and process various 
data streams as they are received, i.e. in "rear time. 
RTOS 210 also enables digital media processor 130 to 
respond to operator control via infrared remote control 
109 and infrared receiver 119. RTOS 210 includes a sig- 
nature portfon 21 1 whose use will be further described 
below. Rash EPROM 141 also includes program code 
for the first resident application 220 with its conespond- 
ing signature portion 221. likewise, flash EPROM 141 
includes program code for the second resident applica- 
tion 230 and its corresponding signature portfon 231 
and program code for other reskjent applications to the 
Mth reskient application 240 and its caresponding sig- 
nature portion 241. Rash EPROM 141 optionally 
includes additional put3lic keys including N -1- 1st public 
key 251. N -i- 2nd public key 253 to N Pth public key 
255. These additional public signature keys are similar 
to the N publk; signature keys stored in boot ROM 135. 
Their use will be detailed below. 
[0027] Set top box 110 further includes dynamic ran- 
dom access memory (DRAM) 143 bi-directionally cou- 
pled to digital media processor 130. DRAM 143 is a 
volatile memory thai serves as readAvrite memory to 
temporarily store transient data during normal opera- 
tions. DRAM 143 is preferably embodied by synchro- 
nous memory employing a RAMBUS Interface. Rgure 4 
illustrates an exemplary memory map of DRAM 143. 
DRAM 143 Stores the memory resident part 261 of the 
real time operating system. Depending upon tiie partic- 
ular status of set top box system 100 this memory resi- 
dent part 261 of the RTOS may differ as known in the 
art. DRAM 143 stores tiie memory resklent parts 263 of 
ttie cun^entiy running applfoation or applicatfons. These 
applications may be resMent applications stored in flash 
EPROM 141 or transient applications stored in other 
parts of DRAM 143. Depending upon the status of set 
top box system 100. there may be various applications 
running and their Immediately accessit>le parts will be 
stored in DRAM 143 for faster access than from flash 
EPROM 141 . DRAM 143 also stores transient data 265. 
This transient data 265 includes tenporary data used 
by the various applications as well as tiie current control 
status as controlled by the user via infrared remote con- 
ixo\ 109 and infrared receiver 119. DRAM 143 stores the 
program code of various transient applicatfons such as 
first transient application 271 . second transient applica- 
tion 273 to Qtti transient application 275. Transient 
applications are those loaded via cable modem ill. 
voice band modem 117 or DVD drive 115 that are 
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intended for use only during the current session of set 
top box system 100. These may Include video games, 
Internet browsing and the like. These transient applica- 
tions are loaded into DRAM 143 each time they are 
used and then discarded. DRAM 143 also stores com- 
pressed video in a first-in-first-out (FIFO) buffer 280. 
Video data from television cable 101, direct satellite 
receiver front end 103 and DVD 105 will generally be 
transmitted In compressed form. This saves transmis- 
sion bandwidth and storage space. One of the tasks of 
digital media processor 130 is to decompress the video 
data. Current video compresston formats (such as 
MPEG2) and all contenplated future video compres- 
sion formats are non-linear. That is. the cfifferent por- 
tions of the video data stream are compressed to 
differing degrees. Thus a constant rate of received 
video data represents varying amounts of video. Follow- 
ing decompression, digital media processor must sup- 
ply video data in a constant rate to be viewed, 
Compressed vkieo FIFO buffer 270 is necessary to 
smooth out the variations in the rate of receipt. This per- 
mits the decompression process to neither overflow with 
too much compressed data nor underflow with no (X)nv 
pressed data ready for decompression. This is possible 
because the compressed video data stream represents 
a constant rate vkJeo data stream that is to be viewed, 
Thus the overall average compressed vkieo data rate 
corresponds to the constant real time viewing rate. 
[0028] Figure 5 is a ftow chart 300 of an example of 
digital media processor 130 operations controlled by 
boot ROM 135. Upon each initial application of electric 
power to set top box system 100. digital media proces- 
sor begins executing the program stored in a predeter- 
mined location within boot ROM 135. Those portions of 
this program within boot ROM 135 relevant to disclosure 
of the present application are illustrated in Rgure 5. Pro- 
gram 300 first inHialized digital media processor 130 
(processing block 301). This process would include 
clearing registers and caches, setting the initial operat- 
ing mode and the like, in a manner known in the art. Fol- 
lowing initialization of the processor, program 300 reads 
the signature portion 211 of RTOS 210 stored in flash 
EPROM 141 (processing block 302). Program 300 next 
reads the RTOS pubfic key 203 from boot ROM 135 
(processing block 303). Next program 300 verifies the 
signature portion 211 of RTOS 210 (processing block 
304). In accordance with the known art of public key 
encryption such as the RSA algorithm, signature por- 
tion 21 1 is produced by operating upon all of RTOS 210 
with a secret private signature key. The original data of 
signature portion 21 1 is recovered by a reverse process 
employing RTOS public signature key 203 stored in boot 
ROM 135. This signature verification process takes into 
account what is know as a "trap door* function. It is a 
very difficult process to produce a particular signature 
portion knowing only the pufcrfic key. A change of any 
portion of RTOS 210 is very likely to result in a change 
in the signature portion 211 in a manner that cannot be 



predicted from only the RTOS public signature key 203. 
Thus it is possible to detect any change in RTOS 210 
employing the signature portion 21 1 . 
[0029] Following the verification, program 300 tests 

5 the verified signature portion to determine if RTOS 210 
supports secure applications (decision block 305). The 
preferred embodiment of the secure computing system 
of the present appRcation contemplates that digital 
media processor 130 could be embodied in appFications 

10 not requiring the security of set top boxes. In such appli- 
cations, the verified signature portion 21 1 indicates that 
the RTOS need not be secured. Note that even a non- 
secure RTOS must have its stub verified. Failure of the 
signature verification is fatal whether the RTOS is 

75 secure or non-secure. Program 300 bypasses other 
steps and starts RTOS 210 (processing block 310) if 
this signature portion 211 indicates a non-secure use. 
This will typically involve foading at least a portion of 
RTOS 210 into DRAM 143. It is anticipated that DRAM 

20 143 wilt allow nruch faster memory access than flash 
EPROM 141. Thus loading portions of RTOS 210 into 
DRAM 143 will enable faster operation. 
[0030] If the verified signature portion indicates that 
RTOS 210 is to support secure applications (decisk>n 

25 block 305). then program 300 tests to determine if 
RTOS 210 can be verified as correct (decision block 
306). As described above, the trap door function of the 
private key signature with pubTic key signature makes it 
a very difficult task to nrxxiify RTOS 210 without produc- 

do ing an unpredictable nxxjification of signature portion 
211. Thus the initial program stored in boot ROM 135 
will almost certainly be able to detect unauthorized 
modification of RTOS 210. This verification of RTOS 
210 permits the vendor of set top box system 100 to t)e 

35 conf kJent of the security of the system. 

[0031] If the verified signature portion is not verified as 
secure, tiien prograin 300 indicates ttiat RTOS 210 is 
norvsecure (processing block 307). Thereafter program 
300 takes remedial action (processing block 308). This 

40 remedial action can take many forms. At the most 
severe, this remedial action could be complete disable- 
ment of set top box 110. Shutting down media proces- 
sor 130 will disable set top box 110 since it is tiie 
intelligence of set top box 110. In most secure applica- 

4S tions running a non-verified RTOS woukJ be considered 
very dangerous and the only reasonatsle remedial 
action is disabling set top box 110. In a few cases a less 
severe remedial action may t>e appropriate. As a less 
severe remedial measure, digital media processor 130 

so could be programmed to no longer interact with video 
data streams from television cable 101. direct satellite 
receiver front end 103 and/or DVD 105. This nxxJe may 
permit running local only transient applications. The 
remedial action could include signaling the set top box 

55 vendor or service provider of the security violatk)n via 
cable modem 1 1 1 or voice band modem 1 1 7. The redp- 
ient of this notification couki then determine either auto- 
matically or manually how to deal witti the security 
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violation. One method of responding to such a nofrfica- 
tion of a security violation is to download via cable mode 
11 1 or voice band modem 1 1 7 an authorized copy of the 
RTOS for staage in flash EPROM 143. ovenwriting the 
unauthorized copy. Another method Is to download a 
diagnostic program which will verify and determine the 
extent of the security violation. At the least severe level 
most suitable for service providers who supply only 
advertiser supported program material, is to Ignore the 
security violation and permit operation of the non- 
secure FH'OS. 

[0032] If the verified signature portion is verified as 
secure, then program 300 indicates that RTOS 210 as 
verified (processing block 309). Thereafter program 300 
starts operation of RTOS 210 (processing block 310). 
As described above this would typically Involve copying 
at least portions of RTOS 210 from flash EPROM 141 to 
DRAM 143. Following such a copying, program control 
would be transfen-ed to the RTOS copy in DRAM 143 
via a jump instruction. RTOS 210 then enables all the 
authorized functions of set top box system 100. 
[0033] The entire RTOS could be encrypted using the 
private key as an alternative to employing merely a sig- 
nature verification process. The steps illustrated in Fig- 
ure 5 would be similar except that the entire RTOS must 
be deaypted using the public key rather than just the 
signature portion. In this event the decrypted RTOS 
wouM be copied to a operating portion of DRAM 143 
upon verification. Thereafter program control would be 
passed to this copy of the RTOS from the boot ROM 
program via a jump instruction. In this case a non-veri- 
fied RTOS even if copied into the same part of DRAM 
143 will not operate. An incorrect decryption of an unau- 
thorized RTOS 210 would likely result in an inoperable 
operating system. Thus the remedial action is this case 
disables set top box 1 10, Note the use of a private key 
to encrypt and a public key to decrypt is the reverse of 
the usual private key/^iislic key system. Currently, only 
the RSA system is known to permit this reverse use. 
[0034] Figure 6 is a flow chart 400 of an example of 
digital media processor 130 operations when called to 
load and run a reskient applk:ation. Following the com- 
mand to start the resident application program 
(processing block 401), program 400 reads the corre- 
sponding signature portion of the reskient application 
stored in flash EPROM 141 (processing block 402). Pro- 
gram 400 next reads the corresponding public key from 
boot ROM 135 or flash EPROM 141 (processing bk)ck 
403). As noted above in the memory maps of boot ROM 
135 and flash EPROM 141, the public keys for resident 
applicatk)n programs may be stored in boot ROM 135 or 
in flash EPROM 141 . Alternatively, set top box 100 may 
be constructed so that the pdtHlc keys for some resident 
applications are stored in boot ROM 135 and the public 
keys for the remaining resident applications are stored 
in flash EPROM 141. Next program 400 verifies the sig- 
nature portion of the reskient application (processing 
block 404). This signature verification process is the 



same as previously described in conjunction with verifi- 
cation of RTOS 210. 

[0035] Following the verifk^tion, program 400 tests 
the verified signature portion to determine if the resident 

5 application supports security (decision block 405). It is 
contemplated that any resident applk:ation that interacts 
with program content received from televisk>n cable 
101. direct satellite receiver front end 103 or DVD 150 
will require security. Other resident applications may 

10 require security at the optton of the applk:ation program 
vendor. Program 400 bypasses other steps, toad the 
resident application into DRAM 143 and starts the appli- 
cation program (processing block 410) if this signature 
portion indicates a non-secure use. 

IS [0036] If the verified signature portton indicates that 
the resident application is to support secure applica- 
tions (dedsion block 405). then program 400 tests to 
determine if the resident application can be verified as 
correct (dedsion block 406). The trap door function of 

so the private key encryptkm with public key deayptioh 
makes it a very diff kxdt task to modify the reskient appli- 
cation program without produdng an unpredictable 
modification of signature portion, thus enat)ling verifica- 
tion of the authorization of the resident application. 

2S [0037] If the signature portton is not verified as secure, 
then program 400 indicates that the reskient applk:ation 
is non-secure (processing block 407). Thereafter pro- 
gram 400 takes remedial action (processing block 408). 
This remedial action couU be any of the many forms 

30 described above. 

[0038] If the signature portion is verified as secure, 
ttien program 400 indicates that tiie reskient appPication 
as verified (processing block 409). Thereafter program 
400 starts the reskient application by transfening at 

35 least part of its program code to DRAM 1 43 and trans- 
ferring control via a junrp instruction, It is contemplated 
that resident application programs will have access to 
less than all of the digital media processor functions 
accessible via RTOS 210. 

40 [0039] The entire resident application could be 
encrypted using the private key as described above. 
The steps illustrated in Figure 6 would be similar except 
tiiat the entire resident application must t>e decrypted 
using the public key rather than just the signature por- 

45 tion. As previously described, using this technique 
means that an unauthorized program wiH probably 
crash and disable set top box 1 10. 
[0040] Figure 7 is a f tow chart 500 of an example of 
verification of a downloaded program. Following the 

50 command to start downloading an application program 
(processing block 501), program 500 downtoads the 
appltoation as stores it in DRAM 143 (processing block 
502). Then program 500 reads the corresponding sig- 
nature portion of the downloaded application stored in 

55 DRAM 143 (processing block 503). Program 500 next 
reads the corresponding public k^ from boot ROM 135 
or flash EPROM 141 (processing block 504). As noted 
above In the memory maps of boot ROM 135 and flash 



7 



13 



EP0 961 193 A2 



14 



EPROM 141, the public keys for resident application 
programs may be stored in either boot ROM 135 or in 
flash EPROM 141. Next program 500 runs signature 
verification on the downloaded application program 
(processing block 505). This signature verification proc- 
ess is the same as previously described in conjunction 
with verification of RTOS 210. A secure application pro- 
gram will have a signature portion that permits verifica- 
tion of the entire downloaded application program. A 
non-secure application program will have a verifiable 
signature stub. 

[0041 ] Program 500 next tests to determine if the sig- 
nature or signature stub has been verified (deds'ibn 
block 506). If the signature or signature stub has not 
been verified as proper, then program 500 would indi- 
cate a security violation (processing block 507) and take 
remedial action (processing block 508). This remedial 
action couki be any of the many forms described above. 
In addition, another possible remedial action in this 
instance is to make an further attempt to download this 
application. Thus program 500 couki loop back to 
processing block 502 to repeat the download. This 
remedial action wouU permit recovery if an authorized 
application was corrupted, such as by noise or the like, 
during download. If tNs option is used, it is preferable to 
abort this loop if after a predetermined nuniber of signa- 
ture verification failures. 

[0042] Following successful verification of the signa- 
ture or signature stub, program 500 tests the verified 
signature portion to determine if the dovmloaded appli- 
cation supports security (decision block 509). Program 
500 bypasses other steps, stores and runs the down- 
loaded application program (processing block . 512). if 
this signature portion indicates a non-secure use. Note 
that the downloaded application program may be 
loaded into flash EPROM 141 if it is intended to be 
another resident application or into DRAM 143 if it is 
intended to be a transient applicatkxi. 
[0043] If the verified signature portion indicates that 
the downloaded application program supports secure 
applications (decision block 509), then program 500 
tests to determine if the downloaded application can be 
verified as correct (decision btock 51 1). The trap door 
function makes it a very difficult task to modify the 
downloaded application program without producing an 
unpredictable modifk:ation of signature portion, thus 
enabling verification of the authorization of the down- 
loaded application program. 
[0044] If the downloaded application program is not 
verified as conrect (decision block 510). then program 
500 indicates that the downloaded application Is non- 
secure (processing block 507). Thereafter program 500 
takes remedial action (processing block 508). This 
remedial action could be any of tiie many forms 
described above and may include making a further 
attempt to download this application program. 
[004^ If the downtoaded application is verif ied as cor- 
rect (decision block 510). then program 500 indicates 



tiie downloaded application is secure (processing block 

511) . Thereafter program 500 stores and runs tiie 
downloaded application program (processing block 

512) . As described above, this storage will be in flash 
5 EPROM 141 if the applicatton is a resident application 

or in DRAM 143 if the application is a transient appPica- 
tion. Program 500 starts the downloaded application 
program by transferring at least part of its program code 
to DRAM 143 and transferring control via a jump 
10 instruction. 

[0046] The entire downloaded application program 
oouti be encrypted using tiie private key as described 
above. The steps illustrated in Figure 7 wouM be similar 
except that the entire downloaded applk;ation must be 
IS decrypted using tiie public key ratfier than just verifying 
ttie signature portion. As previously described, using 
tills technkiue means that an unauthorized program will 
probably crash and disable set top box 1 10. 
[0047] This security technk^ue relies upon the security 
20 of boot ROM 1 35. Since boot ROM 1 35 is located on tiie 
sane integrated circuit as tiie otiier parts of digital media 
processor 130 and It is a read-only, it is not subject to 
unautiiorized change. Therefore the verifk»tion function 
cannot be changed to verify a unautiiorized RTOS. 
^5 Many of the security functions will be available only to 
tiie RTOS based upon program privilege levels. Thus 
most security functk)ns cannot be easily compromised. 
The private key used fbr encryption will only be known 
to the RTOS supplier, or only to tiie manufacturer of dig- 
so ital media processor 130. In addition the public key 
needed to verify the signature or to deaypt the RTOS is 
also in the boot ROM. This prevents substitutton of 
another public key in an attempt to cause digital media 
processor 130 to verify an unauthorized RTOS. Addi- 
35 tionally. the resident applications are also secure. The 
private keys for resklent applications can be known only 
by the application owner, or by the service provider who 
authorizes the applteation. 

[0048] The above private key^ublic key signature ver- 

40 ification system will protect against most security 
attacks. However, if the private key used to authenticate 
tiie RTOS is compromised, the security may be 
defeated by replacing the RTOS with an unauthorized 
RTOS which will still look authentia 

45 [0049] The simplest way to detect a modified RTOS 
woukf be to check the reskJent RTOS against tiie 
authorized program. An application program, such as a 
diagnostic program, could read certain memory ioca- 
tions in the RTOS to see if they contain the expected 

50 values. This may not always reveal unauthorized sutssti- 
tution of anottier RTOS. Many complex data processors 
such as woukl be used to embody digital media proces- 
sor 130 support virtual memory. In a virtual memory 
environment tiie RTOS is quite capable of virtualising 

55 itself. Thus tiie unautiiorized RTOS wouM intercept the 
confirming read attempts and return the results that tiie 
diagnostic application expects from a copy of tiie 
autiior'ized RTOS. However, this unautiiorized RTOS 
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would run instead of the original RTOS consequently 
compromising security. The present application pro- 
pose a technique which assures that an application can 
access a portion of memory directly without being inter- 
cepted and translated to a virtual address by the RTOS. 
[00501 Figure 8 illustrates in block diagram form a 
translation look-aside buffer (TLB) 137 having a locked 
page in accordance with the teachings of the present 
application. Virtual memory applications translate a vir- 
tual address into a physical address. As is known in the 
art, TLB 137 receives a virtual address on bus 601 and 
supplies a corresponding physical address on bus 602. 
A predetermined number of most significant address 
bits of the virtual address are supplied to a plurality of 
comparators 621. 623, 625 and 627. The remaining 
least significant address bits of the virtual address on 
bus 601 are passed unchanged to the corresponding 
bits of physical address on bus 620. Each conparator 
621. 623, 625 and 627 has a corresponding virtual 
address register 611, 613. 615 and 617, respectively. 
The conparators 621, 623, 625 and 627 determine H 
the predetermined number off most significant bits of the 
virtual address on bus 601 matches the contents of the 
respective registers 611. 613. 615 and 617. Each com- 
parator 621. 623. 625 and 627 supplied match indica- 
tton to multiplexer 650. Multiplexer 650 supplies the 
predetermined number of most significant bits from one 
of the physical address registers 641 . 643. 645 and 647. 
The physteal address register selected by multiplexer 
650 corresponds to the comparator 621. 623. 625 or 
627 detecting a match. These nx)St significant physical 
address bits selected tyy multiplexer 650 are supplied to 
the most significant bits of the physical address on bus 
602. Thus TLB 137 substitutes a predetern^ned 
number of bits of a physical address for the same 
number of bits of the virtual address. The number of 
possible substitutions enabled by the virtual address 
re^ster and its corresponding comparator arxf physical 
address register is limited only by considerations of 
operation code space to access the registers and the 
amount of space occupied by the TLB. In the prior art 
virtual address registers 611. 613. 615 and 617 and 
physical address registers 641. 643. 645 and 647 are 
alterable via software. Thus the real time operating sys- 
tem has control of the mapping of virtual addresses to 
physical addresses. 

[0051] In the prefen-ed embodiments of the disclosed 
secure computing system one of the virtual address 
registers and the corresponding physical address regis- 
ter are fixed upon manufacture. In the preferred embod- 
iment this pair of registers are mask programmable at 
metal layers, permitting the locked page to be selected 
upon manufacture of the integrated circuit including TLB 
137 but unalterable following manufacture. Rgure 8 
illustrates a fixed virtual address register 611 and its 
corre^nding fixed physical address register 641. In 
the preferred embodiment the virtual address stored in 
fixed virtual address register 621 equals the physical 



address stored in fixed physical address register 641 . In 
the prefen-ed embodiment, the aitical code to be pro- 
tected from relocation will be stored in flash EPROM 
141 within the boundary of physical addresses covered 

5 by this virtual address register. Attempts to write to 
either fixed virtual address register 61 1 a fixed physical 
address register 641 will fail because these registers 
are fixed in hardware. Preferably there will be no faults 
or errors generated by an attempt to modify these regis- 

70 ters. Alternatively, neither the fixed virtual address reg- 
ister 61 1 nor the f ixed physical address register 641 are 
accessible via the instruction set architecture. Since the 
reason tiiat fixed virtual address register 611 or fixed 
physical address register 641 are fixed is to prevent 

15 alteration, no access via tiie instiruction set architecture 
would ever be required. 

[0052] A further feature of the disclosed embodiment 
of the present application is illustrated in Rgure 8. Note 
that the match indk^ation from comparator 621 is sup- 

20 plied directiy to multiplexer 650. The match indication 
from other comparators form the noninverting input to 
respecth^e AND gates 633. 635 and 637. Each of these 
AND gates 633. 635 and 637 receives ttie match indica- 
tion from conparator 621 on an Inverting input. Thus a 

25 match indication from comparator 621 prevents supply 
of a match indication to multiplexer 650 from any other 
comparator. This prevents an unauthorized person from 
leaving the original RTOS in place to respond to security 
queries while attempting to run an unauttiorized RIDS 

30 from a relocated part of memory. Any memory accesses 
to the physical memory addresses of virtual address 
register 611 and physical address register 641 cannot 
be relocated but are directed to the physical address of 
the original RTOS. 

35 [0053] With ttie disclosed enri)odiment of ttie present 
application an unauthaized attempt to relocate the 
RTOS may occur, but no actual address translation will 
take place. Thus if the original RTOS is always located 
in this manory area, a diagnostic program can read sig- 

40 nature locations with assurance that the original physi- 
cal k)cations are being accessed. Thus the diagnostic 
program can determine if the RTOS is compromised, 
and take appropriate remedial action. This remedial 
action may include any of the remedial acttons previ- 

4S ously descrbed. 

[0054] The set top box 100 iDustrated in F^ure 1 
includes an additional potential security problem. 
DRAM 143 stores a video data stream that has been 
decrypted but not decompressed. Th^ vkjeo data is 

so stored in compressed video FIFO buffer 280. ft is possi- 
ble for an unauttiorized person to intercept ttiis data as 
it is being transfen^ed from digital media processor 130 
to DRAM 143 or as It is being transfen^ed from DRAM 
143 and digital media processor 130. These data trans- 

55 fers will be interleaved witii ottier data traffic between 
digital media processor 130 and DRAM 143. but it is 
feasible to separate ttie compressed video data. 
Because ttie video is compressed, a minimal amount of 
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memory would be required to store this data. Some 
content providers would like to prevent their video pro- 
gramming from such interception. Note that interception 
of the video data stream at this point would permit gen- 
eration of plural, identical and immediately viewable 
copies of the videa 

[0055] Figure 9 illustrates in flow chart form a process 
preventing such unauthorized interception. Following 
reception of the video data stream (processing block 
701} digital media processor 130 decrypts the video 
data stream (processing block 702). TNs decryption is 
subject to security procedures to ensure that the user is 
authorized to view this video data stream. Following this 
decryption of the source program, digital media proces- 
sor encrypts the video data stream again (processing 
block 703). In this instance a relatively simple encryp- 
tion is used, such as a sinplified DES algorithm. The 
encryption key is preferably derived from the chip iden- 
tity number stored in chip identity register 133. This 
encrypted data is stored In conrpressed video FIFO 
buffer 280 (processing block 704). At the appropriate 
time, the video data is recalled from compressed video 
FIFO buffer 280 (processing block 705). The recalled 
data is decrypted using the encryption key derived from 
the chp identity number (706). This data is then ready 
for furtiier processing (processing block 707). 
[0056] This technique has the advantage tiiat the 
conrpressed video data stream temporarily stored in 
compressed video FIFO buffer 280 can only be read by 
the particular digital media processor 130. The chip 
identity number is unique to that particular digital media 
processor. The video data cannot be viewed by any 
other means, even another identical set top box system 
100 without breaking the coda This is believed ade- 
quate security by most content providers. Additionally, 
tiie encryption and decryption is transparent to the user. 
There only needs to be a small additional processing 
capacity available within digital media processa 130 
beyond the minimal requirement of the partk:ular appli- 
cation. 

[0057] Another potential security problem is created 
1^ the hardware debugger/ emulator. The semiconduc- 
tor manufacturer of digital media processor 130 wiH 
generally also sell hardware detxjgger/emulator sys- 
tems to application program developers, including oper- 
ating system developers. Generally such hardware 
debugger/emulator systems by design have unlimited 
access to all of memory, including "private" areas. Thus 
a hardware debugger/emulator system of the type 
known in the art wouU pern^ unauthorized breach of 
the security of set top t>Qx system 100. 
[0058] The following modiftoation to the hardware 
debugger/emulator system will guard against this 
potential security problem. The hardware debug- 
ger/emulator will operate in two modes, a process mode 
and a raw nmde. In the process mode, the hardware 
debugger/emulator may only access a particular proc- 
ess or application program. All system access is permit- 



ted in the raw mode. 

[0059] Figure 10 is a flow chart illustrating the process 
of selecting the mode at the hardware debugger/emula- 
tor. Upon start of the hardware det>ugger/ emulator 

5 (processing block 801). process 800 reads the signa- 
ture portion 211 of RTOS 210 stored in flash EPROM 
1 41 (processing block 802). Process 800 next reads the 
RTOS public key 203 from boot EPROM 135 (process- 
ing block 803). Next process 800 verifies tiie signature 

10 portion 211 of RTOS 210 (processing block 804). Fbl- 
k)wing ttie verifk:ation. process 800 tests the verified 
signature portion to determine if RTOS 210 supports 
secure applications (decision block 805). As previously 
described, digital media processor 130 could be 

IS enidodied in applications not requiring tiie security of 
set top boxes. In such applications, the verified signa- 
ture portion 211 indicates that the RTOS need not be 
secured. If this is tiie case, then process 800 bypasses 
otiier steps activates the hardware debugger/emulator 

20 In raw mode (processing block 806). 

[0060] If tiie RTOS supports secure appfications 
(decision block 805). then process 800 checks to deter- 
mine if the chip identity number stored in ch'p identity 
register 133 Is of tiie sut>set of possible chip identity 

25 numbers ttiat permit the raw mode for secure applk»- 
tions (decision block 807). Some program developers, 
particularly RTOS developers, will need access to the 
raw mode of the hardware detxigger/emulator. The 
present application contemplates that a bit or bits or 

30 some subset of the possible coding of tiie chip identity 
number will be reserved for hardware debugger/emula- 
tors supporting this usa Thus only a certain limited 
number of the digital media processors 130 will permit 
raw mode operation of the hardware debugger/emulator 

35 in environments supporting the security described 
above. The manufacturer of digital media processor 130 
will supply these particularly identified chips only to 
trusted program developers. 

[0061] If tiie chip identity number does not permit raw 

40 mode operation (decision block 807), process 800 
reads a token from tiie particular process or application 
program under development in the hardware debug- 
ger/emulator. Process 800 then determines If this token 
is verified as proper (decision block 809). This process 

45 could take place using ttie private key encryption and 
public key decryption descnl^ed above, or another veri- 
fication procedure could be emptoyed. If the token is not 
verified (decision block 809). then process 800 take 
appropriate remedial action (processing block 810). The 

50 various types of remedial action that could be taken 
have already been deserved. If the token is verified 
(decision block 809). then process 800 activates the 
hardware debugger/emulata in process mode 
(processing block 81 1). In the process mode, the hard- 

55 ware debugger/emulator may only access a particular 
process or appfication program corresponding to the 
verified token. 

[0062] This process satisfies all the requirements of 
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the users. Program developers who use digital media 
processor 130 is non-secure application will have com- 
plete access to the functions of the hardware debug* 
ger/emulator. Program developers who use digital 
media processor 130 is secure applications will have 
access limited. Most of those program developers win 
use the secure RTOS and have access only to their own 
programs as identified t>y the token enaypted with their 
corresponding private key. RTOS developers will have 
complete system access but only to particular digital 
media processors having the proper chip identity num- 
bers. Thus the manufacturer of digital media processor 
130 can have the proper level of control in order protect 
the security of set top box systems 1 00. 
[0063] The exemplary embodiments of this patent 
application have been described in conjunction with a 
particular type system requiring computer security, i.e. 
the set top box. Those skilled in the art would realize 
that the use of these security techniques are not limited 
to this example Particularly, almost any computer sys- 
tem requiring that some functions have a degree of 
security may empk>y these techniques. 

Claims 

1. A secure computing system comprising: 



memory Includes an application program for coop- 
erating with said real time operating system, said 
application program including a second verifk»tion 
code encrypted with a predetermined second pri- 
5 vate key; 

said read only memory further being arranged 
for storing a second public key corresponding 
to said predetermined second private key. and 

10 said initialization program further including 

instructions for causing said data processor to 
employ said second public key to deaypt said 
second verification code of said application 
program stored in said non-volatile memory, 

15 and to indicate verification of security of said 

application program or non-verif k:atk)n of secu- 
rity of said application program. 

4. The secure computing system of claim 1. wherein 
20 said at least one program stored in said non-volatile 
memory includes a real time operating system for 
said secure computing system and a plurality of 
application programs for cooperating with said real 
time operating system, each of sakf application pro- 
25 grams including a corresponding verification code 
encrypted with a predetermined private key; 



a non-volatile memory for storing program 
code for at least one program, said program 
code including a verification code encrypted so 
wHh a predetermined private key; 
a data processor for data manipulation under 
program control disposed on an integrated cir- 
cuit, said data processor executing a program 
stored at a predetermined address upon each ss 
initial application of electric power; 
a read only memory disposed on said inte- . 
grated circuit for storing a public key corre- 
sponding to said predetermined private key 
and for storirig an initialization program stored 40 
beginning at said predetermined address, said 
initialization program including instructions for 
causing sakJ data processor to employ said 
public key to deaypt said verification code of 
said at least one program stored in said non- 4S 
volatile menx>ry, said initialisation program fur- 
ther including instructions for causing said data 
processor to indk»te verif ication of security of 
said program or non-verification of security of 
said program. so 

2. The secure computing system of claim 1. wherein 
said at least one program stored in said non-volatile 
memory comprises a real time operating system for 
said secure computing system. 55 

3. The secure computing system of claim 2, wherein 
sakJ at least one program stored in said non-volatile 



said read only memory being an^anged for stor- 
ing a public key conesponding to each of said 
predetermined private keys, and sakJ initializa- 
tion program further including instructions for 
causing said data processor to employ said 
corresponding public key to decrypt said verifi- 
cation code of each of said plurality of applica- 
tion programs stored in said non-volatile 
memory, and to indicate verif kation of security 
of each of said plurality of application programs 
or non-vertfKatk)n of security of each of said 
application programs. 

5. The secure computing system of any of claims 1 to 
4. wherein said initialization program stored in said 
read only memory Includes instructions for causing 
said data processor to disable operation of said 
program upon non-verification of security of sakl 
program stored in sM non-volatile memory. 

6. A secure computing system comprising: 

a memory for storing data and/or instructions at 
corresponding addresses; 
an address generator for generating virtual 
addresses of a first predetermined number of 
bits for accessing data and/or instructions in 
said memory: 

a table look-aside buffer connected to said 
address generator having a fbced virtual 
address register of a second predetermined 
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number of bits less than said first predeter- 
mined number of bits. 

a plurality of writable virtual address regis- 
ters of said second predetermined number s 
of bits. 

a first comparator connected to said 
address generator and said fixed virtual 
address register for comparing the con- 
tents of said first fixed address register io 
with said second predetermined number df 
bits of said virtual address and indicating a 
match. 

a plurality of second conparators, each 
connected to a corespondng virtual is 
address register and said address genera- 
tor, each for comparing the contents of 
said conesponding virtual address register 
with said second predetermined number of 
bits of said virtual address and indicating a 20 
match, 

a fixed physical address register of said 
second predetermined number of bits, 
a plurality of writable physical address reg- 
isters of said second predetermined 2S 
numberof bits, and 

a multiplexer connected to said memory, 
said address generator, said first compara- 
tor, each of said second comparators, said 
fixed physical address register and each of 30 
said plurality of writable physical address 
registers, said multiplexer responsive to a 
match by one of said comparators to sub- 
stitute contents of a physical register con^e- 
sponding to said matching comparator for 3S 
nrx)St significant bits of said virtual address 
and thereby form a physical address sup- 
plied to said memory for memory access. 

7. The secure computing system of claim 6, wherein: 40 

said multiplexer is responsive to an indication 
of a match t>y said first comparator to substitute 
the contents of said fixed physical register for 
most significant bits of said virtual address. 4S 

8. The secure computing system of claim 6 or claim 7, 
wherein said fixed virtual address register and said 
fixed physical address register are mask program- 
mable in manufacture so 

9. The secure computing system of any of claims 6 to 
8. wherein said plurality of writable virtual address 

. registers and said plurality of writable physical 
address registers are writable upon execution of an 55 
instruction by said secure computing system; 

said fixed virtual address register and said 



fixed physical address register writable upon 
execution of an instruction by said secure com- 
puting system, an attempt to write to either said 
fixed virtual address register or said fixed phys- 
ical address register via said instruction being 
arranged to fail to alter contents of said register 
and to generate no error message or fault 

10. A secure computing system comprising: 

a data processor disposed on a single inte- 
grated circuit, said data processor including a 
chip identity read only register for storing a 
unique chp identity number; 
a memory bi-cfirectionally coupled to said data 
processor for storing data; 
said data processor being programmed to: 

(i) encrypt data employing at least a part of 
said chip identity nunrt)er as an encryption 
key, 

(ii) store said encrypted data in said mem- 
ory. 

(iii}recall said stored data from said mem- 
ory, and 

(iv) decrypt said recalled data employing at 
least a part of said chip identity number as 
decryption key 

11. Tlie secure computing system of claim 10. wherein: 

said data comprises a stream of vkleo data. 

12. A method of secure computing comprising the 
steps of: 

encrypting a verifk:ation token for a program 
with private k^; 

storing a public key corresponding to saM pri- 
vate key; 

upon each initialization of a debugger/emulator 
for a secure computing system determining if 
saki program is secure program or a non- 
secure program. 

if said program is a non-secure program select- 
ing a first operating nrxxJe in said debug- 
ger/emulator permitting access to said program 
while prohibiting access to at least one security 
feature of the secure computing system, and 
if sakf program is a secure program selecting a 
second operating mode in said debugger/emu- 
lator permitting access to all features of the 
secure computing system. 

13. The method of secure computing of claim 12. fur- 
ther comprising the steps of: 

storing a unique chip identity number on a data 
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processor within the secure computing system; 
if said program is a secure program testing to 
determine if said unique chip identity number of 
said data processor is within a predetermined 
subset of possible chip identity numbers; s 
if said unique ch^ identity number of said data 
processor is within said predetermined subset 
of possible chip identity numbers selecting said 
second operating mode in said debugger/emu- 
lator; and 10 
if said unique ch^ identity number of said data 
processor is not within said predetermined 
subset of possible chip identity numbers select- 
ing said first operating mode in said debug- 
ger/emulator. IS 

14. The method of secure computing of claim 12. fur- 
ther comprising the steps of: 
wherein said program is an operating system for a 
data processor of the secure computing system; 20 

enaypting with a second private key at least a 
verification token of an appHcation program; 
storing a second public key conresponding to 
sakf second private key; 2s 
deaypting said application program employing 
said put^lic key as a decryption key; 
indicating verlftcation or non-verificatkxi of 
security of said decrypted application program; 
selecting said first operating mode in said so 
debugger/emulator if sakf decrypted applica- 
tion program is verified as secure. 
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